feat(design): add cookie consent and footer - #509

Please address the comments from this code review:

## Individual Comments

### Comment 1
<location path="packages/ecc-utils-design/src/components/compliance-footer/compliance-footer.ts" line_range="178" />
<code_context>
+    // a same-origin frame with both flags could lift its own sandbox
+    const sandbox = isSameOrigin(src)
+      ? "allow-scripts allow-popups allow-popups-to-escape-sandbox"
+      : "allow-scripts allow-same-origin allow-popups allow-popups-to-escape-sandbox";
+    return html`<iframe
+      class="mt-4 h-[60vh] w-full rounded-md border border-border"
</code_context>
<issue_to_address>
**Embedded content escapes sandbox restrictions**

When a visitor interacts with a malicious or compromised external embed, the external-frame sandbox allows popups to escape sandboxing. A malicious or compromised embed can open an unsandboxed popup after a user interaction and use it to navigate the app's top-level window, bypassing the frame's sandbox restrictions.

Omit `allow-popups-to-escape-sandbox` or disallow popups for embedded content.
</issue_to_address>

### Comment 2
<location path="packages/ecc-utils-design/src/components/cookie-consent/consent.ts" line_range="342-343" />
<code_context>
+  config?: CookieConsentConfig
+): () => void {
+  const handler = (event: Event) => {
+    const { detail } = event as CustomEvent<{ consent: CookieConsent }>;
+    if (detail?.consent) listener(detail.consent);
+  };
+  const storageHandler = (event: StorageEvent) => {
</code_context>
<issue_to_address>
**Other configurations receive consent**

When multiple consent configurations with different storage keys are used on the same page and one saves consent, `onConsentChange`'s same-window handler forwards every `CONSENT_CHANGED_EVENT` payload without matching the subscribed config's storage key or signature, so listeners receive unrelated choices and can enable optional behavior without consent for their configuration.

Match each event's consent to the subscribed configuration's storage key or signature before invoking its listener.
</issue_to_address>

### Comment 3
<location path="packages/ecc-utils-design/src/components/cookie-consent/cookie-consent.ts" line_range="108" />
<code_context>
+  private listen(): void {
+    this.stopListening?.();
+    this.stopListening = onConsentChange(() => {
+      if (!this.dialog?.open) this.refresh();
+    }, this.config?.cookies);
+  }
</code_context>
<issue_to_address>
**Stale preferences overwrite newer consent**

When one tab changes consent while another tab's preferences dialog is open, and the second tab then saves, `listen()` skips `refresh()` while the dialog is open, so this tab's `choices` remain stale; saving them calls `saveConsent()` for every category and overwrites the other tab's newer choices.

Reconcile incoming consent with the dialog's edits before saving, or detect that consent changed since the dialog opened and refresh or ask the user to resolve it.
</issue_to_address>

### Comment 4
<location path="packages/ecc-utils-design/src/components/cookie-consent/consent.ts" line_range="323-324" />
<code_context>
+    updatedAt: new Date().toISOString(),
+  };
+  writeItem(consentStorageKey(config), JSON.stringify(consent));
+  window.dispatchEvent(
+    new CustomEvent(CONSENT_CHANGED_EVENT, { detail: { consent } })
+  );
+  return consent;
</code_context>
<issue_to_address>
**Reentrant saves deliver stale consent**

When an earlier consent-change listener saves consent while handling an event, and a later listener also reacts to consent changes, `dispatchEvent()` invokes listeners synchronously, so an earlier listener that calls `saveConsent()` dispatches a newer event before the outer dispatch reaches later listeners; those listeners then receive the newer consent followed by the stale one and can re-enable behavior after a revocation.

Queue consent notifications and drain them in save order rather than allowing nested dispatches to overtake the outer event.
</issue_to_address>

### Comment 5
<location path="packages/ecc-utils-design/src/components/cookie-consent/consent.ts" line_range="314" />
<code_context>
+  }
+  const categories: Record<string, boolean> = {};
+  cookieCategories(config).forEach((category) => {
+    categories[category.id] =
+      !!category.required || consent.categories?.[category.id] === true;
+  });
</code_context>
<issue_to_address>
**The special category choice is lost**

When a configured category has the ID `__proto__`, `saveConsent()` assigns the category into ordinary objects, so the inherited `__proto__` setter prevents the choice from being stored or serialized; reads then miss the consent and the preference can appear enabled regardless of the user's choice.

Use prototype-safe records or equivalent own-property handling for category choices and saved consent.

Also at `packages/ecc-utils-design/src/components/cookie-consent/cookie-consent.ts:138-139`, `packages/ecc-utils-design/src/components/cookie-consent/consent.ts:273-276`.
</issue_to_address>

### Comment 6
<location path="packages/ecc-utils-design/src/components/cookie-consent/consent.ts" line_range="190" />
<code_context>
+ * @param config Cookie consent configuration
+ * @returns The categories
+ */
+export function cookieCategories(
+  config?: CookieConsentConfig
+): CookieCategory[] {
</code_context>
<issue_to_address>
**Duplicate categories conflict**

When configured categories contain duplicate IDs with conflicting `required` values, including a non-required `necessary` category when the default is added, `cookieCategories()` retains duplicate IDs, so the preferences can show conflicting switches while `saveConsent()` stores one value per ID and `hasConsent()` can treat the category as granted even after rejection.

Deduplicate category IDs while preserving the required category's consent semantics.

Also at `packages/ecc-utils-design/src/components/cookie-consent/consent.ts:193-198`, `packages/ecc-utils-design/src/components/cookie-consent/consent.ts:292-298`, `packages/ecc-utils-design/src/components/cookie-consent/consent.ts:314-315`.
</issue_to_address>

### Comment 7
<location path="packages/ecc-utils-design/src/components/cookie-consent/consent.ts" line_range="193" />
<code_context>
+export function cookieCategories(
+  config?: CookieConsentConfig
+): CookieCategory[] {
+  const categories = (config?.categories ?? []).filter(
+    (category) => category && typeof category.id === "string" && category.id
+  );
</code_context>
<issue_to_address>
**Malformed config breaks rendering**

When runtime deployment configuration supplies a non-array `cookies.categories` or `footer.items` value, `cookieCategories` or `footerItems` calls `.filter()` on the configured value, so a deployment setting with `categories` or `items` set to a non-array throws during component updates and the consent or footer UI fails to render. No runtime shape check catches this.

Validate these fields as arrays before filtering and fall back safely or report the invalid setting.

Also at `packages/ecc-utils-design/src/components/cookie-consent/consent.ts:374`.
</issue_to_address>

### Comment 8
<location path="packages/ecc-utils-design/src/components/cookie-consent/cookie-consent.ts" line_range="124" />
<code_context>
+  private async openDialog(item: DialogItem): Promise<void> {
+    this.openItem = item;
+    await this.updateComplete;
+    if (this.dialog && !this.dialog.open) this.dialog.showModal();
+  }
+
</code_context>
<issue_to_address>
**Detached dialogs reject opening**

When the component is removed after an open request schedules an update but before `updateComplete` resolves, `showModal()` runs after an `await` without checking whether the component is still connected; removing the component while its update is pending leaves the dialog detached, so `showModal()` throws and the preferences or footer page does not open.

After awaiting `updateComplete`, return without opening the dialog if the component is no longer connected.

Also at `packages/ecc-utils-design/src/components/compliance-footer/compliance-footer.ts:107`.
</issue_to_address>

### Comment 9
<location path="apps/documentation/pages/docs/design/components/cookie-consent.mdx" line_range="99" />
<code_context>
+  </Tabs.Tab>
+  <Tabs.Tab>
+    ```html showLineNumbers copy filename="index.html"
+    <script type="module" src="https://esm.sh/@elixir-cloud/design@2.0.0-alpha.50/components/cookie-consent"></script>
+    <ecc-utils-design-cookie-consent></ecc-utils-design-cookie-consent>
+    <script type="module">
</code_context>
<issue_to_address>
**HTML examples load unavailable release**

The package version is `2.0.0-alpha.49`, so these URLs request `2.0.0-alpha.50`, which is not the version built by this PR. Users following either HTML example fail to load the component or load no implementation of the new feature.

Point the examples at the package version that contains these components, or bump the package version to `2.0.0-alpha.50` through the release process.

Also at `apps/documentation/pages/docs/design/components/compliance-footer.mdx:70`.
</issue_to_address>